With the rapid development of wireless data services, increasingly high requirements are imposed on the quality of service (QoS) and charging of the data services. For example, in the 3rd Generation Partnership Project (3GPP) protocol standards, the QoS and charging of the data services are controlled through a policy control method for a service flow. The policy control process for a service flow in the prior art is described below with reference to FIG. 1.
In Step 101, an application function (AF) receives a trigger event (for example, starting of the multimedia).
In Step 102, the AF extracts information, which triggers the event, of an application service from the trigger event, and sends the service information to a policy control and charging rules function (PCRF) through a Diameter authentication-authorization-request (AAR) message.
In Step 103, after receiving the AAR message, the PCRF saves the service information in the AAR message.
In Step 104, if the PCRF does not have subscriber subscription information at this time, the PCRF requests for the subscriber subscription information from a subscription profile repository (SPR).
In Step 105, the PCRF generates a control policy according to policy contexts including an application event, service information, subscriber subscription information, operator policy, access network type, and the like.
In Step 106, the PCRF sends the control policy to a policy and charging enforcement function (PCEF) through a re-authentication-request (RAR) message.
In Step 107, the PCEF returns a re-authentication-answer (RAA) message to the PCRF.
In Step 108, the PCEF exercises a policy decision according to the control policy, for example, initiates a modification to an Internet protocol (IP)-connectivity access network (IP-CAN) session, that is, establishes an IP-CAN bearer or updates the QoS.
In Step 109, if necessary, the PCEF further needs to re-apply for a control policy from the PCRF, that is, the PCEF sends a credit-control-request (CCR) message to the PCRF, so as to request for the control policy; and then, the PCRF returns a credit-control-answer (CCA) message to the PCEF, so as to send the control policy to the PCEF.
In Step 110, the PCRF returns an authentication-authorization-answer (AAA) message to the AF.
As can be seen from the above process, in the policy control process for the service flow in the prior art, the AF sends the service information to the PCRF. The PCRF generates a control policy according to policy contexts including an application event, service information, subscriber subscription information, operator policy, access network type, and the like, and sends the generated control policy to the PCEF, and then the PCEF exercises policy control over the QoS and charging of the application service flow according to the control policy.
However, in certain application services (for example, Skype application and BT application, video on demand (VoD) application, online game application, file transfer protocol (FTP) application, and instant communication applications MSN and QQ, which use a point-to-point (P2P) technology), as no AF is provided, or AFs for such application services are generally not involved in the policy control of the network, the PCRF cannot obtain the application event and service information, and cannot generate a control policy for the service flow according to the application event and the service information. As a result, the PCEF cannot exercise policy control over the QoS, charging, and gating of service flows of the applications based on the control policy.